@jtdavis777 would you review this PR
thank you

this is also a language I am not familiar with, and that I think we do not have an active maintainer of. so will take me some time

@jtdavis777 could you give me any updates for me?

this looks like another chunky feature that will take me a little bit to digest -- what I can say is there is a SupportsAdvancedArrayFeatures feature in the idl_parser I think you will need to enable -- it isn't a well documented area of the code but we will need to make sure Go conforms to all the features under this umbrella.

this looks like another chunky feature that will take me a little bit to digest -- what I can say is there is a SupportsAdvancedArrayFeatures feature in the idl_parser I think you will need to enable -- it isn't a well documented area of the code but we will need to make sure Go conforms to all the features under this umbrella.

Good call on SupportsAdvancedArrayFeatures - that's already enabled in this PR(kGo added to the whitelist in idl_parser.cpp).
I checked Go's coverage against the other backends. Read, mutate, create, and full object API round-trip all work and are tested against arrays_test.fbs. Two small gaps vs C++/Rust:

1. No dedicated struct array mutator - though it still works because D(nil, 0) returns a pointer into the buffer, so you can mutate fields on the returned struct directly.
2. No full-array slice getter (same as TypeScript).

Happy to close either gap if you want full parity.

thanks for the explanation -- I didn't catch in my quick scan of your PR that you had already enabled. I don't think absolute parity is necessary out of the gate as long as basic functionality is present. I will do my best to review this (with some of my free time next week most likely) but I would also love to see if I can ping someone else familiar with flatbuffers Go to chime in

@mustiikhalil do you have any Go experience? :)

I am pretty sure there are some example FBS files that ensure that flatc can generate code for them and at least one of them is a dedicated arrays test. can you poke around and see if we can make sure Go is one of the languages tested with that?

@jtdavis777 Good catch. I looked into it and there are two things I need to hook up:

1. scripts/generate_code.py - this is the central script that generates code from arrays_test.fbs for C++, C#, Java, Rust, Python, and Swift. Go is already included there for monster_test.fbs but not for arrays_test.fbs. I'll add --go to the arrays_test generation call.
2. tests/TestAll.sh - GoArraysTest.sh exists but isn't called here. I'll add it next to GoTest.sh.

I'll get both of those wired up.

@jtdavis777 Good catch. I looked into it and there are two things I need to hook up:

1. scripts/generate_code.py - this is the central script that generates code from arrays_test.fbs for C++, C#, Java, Rust, Python, and Swift. Go is already included there for monster_test.fbs but not for arrays_test.fbs. I'll add --go to the arrays_test generation call.
2. tests/TestAll.sh - GoArraysTest.sh exists but isn't called here. I'll add it next to GoTest.sh.

I'll get both of those wired up.

Updated! please review again @jtdavis777
thanks

test side LGTM - would still love to find another golang person to look this over

@jtdavis777 I hope you had a great weekend. I want to merge this PR if it has no problem. It’s been two weeks since I submitted this PR.😉

@jtdavis777 Any updates for me, please. It has no problem now

@jtdavis777 The CI testing is not relate to my changes. Please check again.

@statxc yes unfortunately we have had a ci regression that is blocking merging anything. Hoping that will be fixed soon

@jtdavis777 Could you please merge this PR? It have been a month since I submitted this PR? Why does it take a long?

@statxc as I have explained elsewhere, I do not work for Google. I am a volunteer with very little time to dedicate to this repository, as much as I enjoy doing so. I also am not an expert in Go, or how it is used in and by flatbuffers, so I am not fully comfortable merging new language feature support without much scrutiny and verification that this is implemented properly and in a way that will work for all flatbuffers Go users. With what little time I have had, I have been focusing on requests which are much easier to digest and are in my areas of expertise. I am very thankful that you have taken the time to implement this feature, and am excited for it to be merged. But unless and until we get more support, pull requests like this will take a while to get reviewed and approved.

I appreciate your patience and enthusiasm for contributing and hope you will continue to do so!

I will close this PR because it took long time since I opened this PR. Not yet merged.